Application control
During a debugging session, the Debugger allows you to start and stop procedure execution as you want, and even execute procedures that are not part of your application. All procedures the Debugger executes are added to the procedure call stack. The procedure call stack is a last-in-first-out (LIFO) memory structure that keeps track of the execution status of each procedure as it calls a subprocedure or invokes a trigger block.
The following sections cover:
Open and incremental execution
To execute a procedure other than the one the Debugger is currently running, open the procedure and start it from the Debugger using Debug
Run. Whenever the Debugger has control, you can run any application, effectively adding it to the procedure call stack of your current application. This allows you to mix and match procedures dynamically or run diagnostic procedures while debugging your application.
When the Debugger is stopped in an executing procedure, you can continue execution using Debug Continue. This allows the procedure to execute until it encounters a breakpoint, an interrupt, or the end of the procedure. You also can continue executing the current procedure line by line using Debug Step Into, Debug Step Out, or Debug Step Over. Use Debug Start Animation to watch your program execute as the Debugger steps through your code. Use the Run to Line command to continue program execution up to a specified line of 4GL code.
Procedure interruption
To selectively interrupt procedure execution, you can set or remove breakpoints using Edit Breakpoints. A breakpoint can be a specific line in a procedure where execution stops temporarily. When the procedure reaches a breakpoint, it halts before executing the specified line and gives control to the Debugger for your next command. The easiest way to set a breakpoint is to click in the left column of the source code pane where the procedure appears.
A breakpoint can be conditional, where evaluation of a logical expression determines whether the interruption occurs. A breakpoint can be based on encountering an error, in which case the Debugger gets control at the next executable line after the line that caused the error.
You can set and remove breakpoints from the 4GL using the DEBUGGER system handle’s SET-BREAK( ) and CANCEL-BREAK( ) methods. This feature is helpful to control breakpoints at specific points in your code, regardless of how the surrounding code is modified, or to set breakpoints in include files that might appear in many different procedures.
To interrupt a running procedure and give control to the Debugger, the Debugger provides a Debug Interrupt command. This interrupts a procedure wherever it is executing, as if it encountered a breakpoint. It is particularly useful when you want to interrupt a procedure in which you have not set a breakpoint.
Interrupt while an alert dialog box is displayed on the screen, or while the procedure is executing a READKEY or PAUSE statement, the Debugger does not take control until you dismiss the alert dialog box or satisfy the READKEY or PAUSE statement.
You can provide a means to interrupt a running procedure from the 4GL by setting the SESSION system handle DEBUG-ALERT attribute to TRUE. This places a Help button on all alert boxes that provides access to a Stack Trace dialog box and the Debugger.
Procedure termination
You can force a procedure to terminate at a break or interrupt point, using Debug Stop. This effectively inserts and executes a 4GL STOP statement at the current break or interrupt point.